Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1183

Internet Message Format | 1994-08-27 | 10.8 KB

Date: Fri, 29 Jul 94 23:13 CDT
From: [e-mail] (Evan K. Langlois)
To: [e-mail]
Subject: Re:  Gem List
Precedence: bulk

========================================================================
Well, I break my library down into a few seperate .C files and the
programmer can pick which ones he wants.  I'm sure that's what most of us do.
========================================================================

Nope, you put EVERY function in a separate C file, roll the whole thing
into a .a or .lib or what have you, and then whatever functions the
programmer uses will be included by the linker.  The linker includes
entire .o files, so the programmer doesn't choose, the LINKER chooses.
This requires libraries to have TONS of files.  Makes a MINIX filesystem
very handy, but that is beside the point.

========================================================================
> Ok, then use XAES. We allow you to drag/resize/scroll/close/et
How do you do this?  HOW?  You can't get anything other than WM_TOPPED
messages to background windows under normal TOS.
Oh, but you're replacing parts of AES, aren't you.  Vector-stealing.
Icky.  Isn't the exception stack frame different on the 68030 compared to
the 68000?
========================================================================

Yes, the stack frame is different.   But its not vectors. It's easier.
Make a window with no gadgets.  Now put gem-objects in it.  These
GEM objects can be anything, even user-defs.   When you get a click
event on that GEM object you control the window through wind_set, so
you will NEVER get a WM_CLOSE or WM_FULL message because those
gadgets don't exist.  It will work, but its a pretty major change.
I've thought about it, but its too much of a change from GEM.  It
IS a nice trick though.

========================================================================
A LITTLE?  Are you kidding?  First I'm going to have to decode the file,
then I'm going to have to translate the codes into what gets displayed,
then I'm going to have to figure out where (and in what character space)
to put them into my menus, then I'm going to have to scan my list every
time the user presses a key, and on top of that, I'm probably going to
have to put up with some brain-dead method of figuring out which key is
which because someone wants to use hardware scancodes for the Ctrl-Letter
keys, which makes no sence because it's non-portable.
========================================================================

It isn't non-portable.  You read for the key, and find the portable
"action" that the user assigned.  Actually, the PROGRAM is portable,
but an app-defs file that uses such will NOT be portable, but who
gives a damn?   They don't need to be unless you really think that
you will carry your app-defs file from a US to a German machine.  And
if you require that level of portability, then don't use scan-codes
in your app-defs!

You don't have to scan a list.  Well, you should, but you could use
the key as an index to a table.  Anyway, you are making things hard
on yourself.  Figuring out which key is which?  You don't NEED to.
You just match the key with the action.  Use a table for the alpha
keys, and then a linked list you can search for symbols and shifted
keys and scan-codes.  Just assign a function pointer to each.

I'm going to try and use the string in app-defs as a selector :-)
It may not work, but I wanna try :-)

========================================================================
KISS:  Keep It Simple, Stupid.
========================================================================

Well, Simple is not always the fastest, or the best.  Many people will
argue that GFA Basic is simple.  The executables produced rarely run
on my machine at all.

========================================================================
7. application interface (every appl reads/evaluates, filecontent stored in
   memory once & accessed through cookie, or server routines through
   cookie (cfr. XHDI/PMMU)).
========================================================================

What?  I hate this idea.  Read a file into memory, then stick a pointer
to it (make sure the memory is globally accessable!!) in the cookie jar.
Now every program has to read the cookie jar in supervisor mode to read
the file.  And, you have to reboot to change the file, since the editor
will edit the file, and you have no semaphores for making a clean change
of the cookie jar pointer (other than the quirk that you are in supervisor
mode).   I might go for the shared memory file system, but what the hell
is wrong with reading a file?   Why take up system memory until its needed?
And since you stick it into global/supervisor accessable memory, I bet
that VM programs will really have a tough time swapping it out.  Please,
just don't.   With a fast hard disk and a good filesystem, reading the
file will be just as fast as playing with cookies.

========================================================================
This is hard to tell.  Is it possible to overflow the AES buffer while
you are _not_ waiting for an event?  If you tell evnt_multi that you are
waiting for MU_KEYBD, and then it returns a keyboard event, will the AES
put another keyboard event in the pipe while you are still processing the
last one?
========================================================================

In single-Tos, no, I don't think so.  At least it would be tough, and
you'd need a pretty poor program.  Considering how fast the average
person can type, a computer sees that as an occasional press that takes
a couple years.  A few hundred thousand to a few million cycles between
key presses?!?   In MultiTOS, the polling and the fact that the AES
actually reads keys while your doing other code can maybe overflow the
buffer.  But in single-Tos, the AES doesn't even get any time to read
a character for you until you call an AES function.  So, if there is
a key waiting for the app to read, the AES won't read another, and the
codes wait around in that huge 128 byte keyboard buffer.

And its not really a pipe, but a buffer area.  Then again, I guess a pipe
really is just a buffer, but message buffer or event queue is less confusing
now that MiNT has real pipes.

========================================================================
He probably means things like image scaling, or multithreading (one
thing you mentioned).  Most users have no need of such, he
believes, and I agree.
========================================================================

Of course a USER doesn't have a need for these.  But a user would like
to see icons the proper size in various resolutions, and would like to
have the system fast and responsive, even when doing full-speed serial
IO.  There is no way to keep an event-driven program and still do
serial IO unless you use multithreading, and even then, you'll need to
fire off some timers now and then to do window updates if you don't get
any other events.  Solutions that check the AES, then check the modem,
and back in a tight loop not only waste CPU time, but you now have
polling and the program isn't really event-driven.

========================================================================
The menu bar works the same way in every application, and always has the
same first entry "Desk".  Most applications use "File" and "Edit" as
========================================================================

Slight change .. Desk should now be the name of your application.
Desk is reserved for the desktop.  Once programs comply, you can figure
out what program the menu bar is for (they are supposed to be nearly
identicle right?) by glancing at the menu bar.

========================================================================
> Confirm on Exit/Save on Exit
> Auto Save Prefs on Exit
Say, the user wants those two on one program, and doesn't want both of those
or just one of those on another program.  To overcome this, he would have
to change the configuration each time he ran the program.  You catch what
I'm trying to say?  This means that he would have to CONFIGURE the program
before he could even do anything!  It's just not practical.
========================================================================

Huh?   No, no, no.  Like this:

*.*.autoSave.yes
*.*.confirmAtExit.yes
*.YourApp.autoSave.no
*.TosWin.autoSave.no

Get it?  Now everything but YourApp and TosWin will autosave.  Everything
confirms at exit.  You can still manually save.  You don't have to change
anything.  In fact, the file is pretty static.  You only need to change
it to change global settings or to change a specific application to do
something different than the global settings you've installed.  You edit
less because if you turn off a global feature, that program you haven't
used in 3 months doesn't have to be reconfigured!

========================================================================
> Its perhaps even more worrying than that, because it hints at misusing the
> AES.
I don't think you have ANY idea of what you're talking about.  I am in no
way "misusing" AES.  How could I *hint* at misusing a standard when I'm using
all of the standard calls the same way that they are documented in the
documentation, and in BOOKS?
========================================================================

Ooh ... Books!   Wow.  What are those?   Is it really necessary to use
all caps?   Books aren't perfect.  Whatever book told you to that defining
your own AES gadgets and using 0ms timer events was OK, was simply wrong.
Can I get the source to your library?  I wanna use it as an example of
how to NOT program a MultiTOS friendly application.

========================================================================
In which case you don't even need a rectangle event, wilbur.  You can just
do a wind_find command, and check to see if the mouse leaves the confines
of the window.  Whoa, that's tough stuff.
========================================================================

OK Mr.Ed.  How are you gonna call wind_find when your waiting on events?
Moving the mouse doesn't cause an event.  When someone clicks the mouse,
its too late, that click could be going to another application.  The
only way to get an event when the mouse leaves the window is to use a
rectangle event.

Yes, I realize that you are using a 0ms timer, however, if you trully
believe that calling evnt_multi(), wind_find(), objc_find(), and vq_mouse()
in a tight loop as fast as the CPU can doesn't waste CPU resources, then
you are wrong.  You are forcing your code to be executed constantly and
you wonder why MultiTos has no time for anything else.   This is VERY
BAD programming.  It is incorrect and damn stupid.

It isn't event driven.  Please learn how to program an efficient event
driven program.  Efficient does not mean fast, but you will notice an
increase in speed especially with multiple apps when you use an event
driven model.  A 0ms timer event is POLLING for events.  Why bother
using the AES at all?